-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Dedup duplicate crates with differing origins in CrateGraph construction #15754
fix: Dedup duplicate crates with differing origins in CrateGraph construction #15754
Conversation
91225bb
to
bf53935
Compare
bf53935
to
1a9b845
Compare
Forgot to move dev deps from lib crate to the local, so please wait for the next commit before reviewing |
fe7f479
to
c3f90bb
Compare
This is ready to be reviewed a third time |
Partially fixes rust-lang#15656 . When a crate graph is extended which is the case when new workspaces are added to the project the rules for deduplication were too strict. One problem that arises from this is that in certain conditions when we see the same crate having different `CrateOrigin`s the first form would be maintained. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in rust-lang#15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.
Make data reflect a case where dev deps are existent. base-db::CrateGraph::extend now adds dev dependencies for a crate in case of its upgrading from a CrateOrigin::Lib kind of a crate to a CrateOrigin::Local one.
ef9bc3e
to
be91d95
Compare
@bors r+ |
… r=Veykril fix: Dedup duplicate crates with differing origins in CrateGraph construction Partially fixes #15656 . Until now the condition for deduplication in crate graphs were the strict equality of two crates. One problem that arises from this is that in certain conditions when we see the same crate having different `CrateOrigin`s the first occurrence would be kept. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in #15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.
💔 Test failed - checks-actions |
7dabf27
to
32f382e
Compare
@bors retry |
That last commit contains nothing? |
(also |
Yeah, last commit is empty, but there was a force-push that did change some paths: https://github.com/rust-lang/rust-analyzer/compare/7dabf2718ef3724d12d9999c120d21df343253c6..32f382e4e8ea841da991ff3c3faade3e4d5052c5. |
32f382e
to
736994f
Compare
@bors r+ |
… r=Veykril fix: Dedup duplicate crates with differing origins in CrateGraph construction Partially fixes #15656 . Until now the condition for deduplication in crate graphs were the strict equality of two crates. One problem that arises from this is that in certain conditions when we see the same crate having different `CrateOrigin`s the first occurrence would be kept. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in #15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.
💔 Test failed - checks-actions |
@bors r=Veykril |
☀️ Test successful - checks-actions |
Normal, | ||
Dev, | ||
Build, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't take this too seriously, as I have retreated to my Zig ivory tower in Lisbon some years ago and am mostly out of touch with the current goings of rust-analyzer, but I would say this is a significant architectural bug.
By design, this layer of rust-analyzer knows nothing about cargo specific concepts. dev-vs-build-vs normal is 100% Cargo concept. rustc
knows nothing about these words. As such, any special handling of these concepts should happen in workspace.rs
, not here.
The motivation for this design is two-fold:
- practically, Cargo is a build system, there might be others. In the core analysis parts, we shouldn't be prioritizing Cargo over other (current and future) build systems
- theoretically, it is important that the internal objects in rust-analyzer's semantic model reflect the physical reality of rustc. In that physical reality, cargo packages do not exists (and
-dev
as a concept applies to a package), there are only units of compilation.
cc @Veykril
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't take this too seriously,
Not at all, you are completely right, this seems incorrect. This was a mistake on my part (I proposed this change somewhere I believe, might've been in DMs).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to check for equality we needed to filter out dev dependencies and thus we ended up with the current state of things. The alternatives were
- To filter them in
project_model
: I am looking into this since @matklad 's first comment here, I do not think it is going to be easy. - Adding
project-model
as a dependency ofbase-db
which is ofc super wrong to do. ( As a matter of fact we already do have aDependencyKind
underproject-model
namedDepKind
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But let me say that I also agree with matklad's concerns so I will look for a way to rectify this.
Partially fixes #15656 . Until now the condition for deduplication in crate graphs were the strict equality of two crates. One problem that arises from this is that in certain conditions when we see the same crate having different
CrateOrigin
s the first occurrence would be kept. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in #15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.